Dan's Web Tips:

"How Do I Force...?"

See also Azerbaijanian, Estonian, French (from tr-ex.me), Greek, Hungarian, Lithuanian, Macedonian, Polish, Portuguese (from https://www.homeyou.com/~edu/), Russian, Slovak, Spanish, and Thai translations (done by others in their own sites)

TIP: Understand that HTML can't "force" any sort of action, and don't keep trying to get around this limitation; you'll just annoy your users and make your site less accessible.

Common "newbie" questions in the newsgroups devoted to Web authoring are those that begin "How do I force the user's browser to..."

not have a "Back" button?
have one of the links on the page work like a "Back" button?
eliminate the past history of the user's browsing so the user can't go back out of my site?
save the past history of the user's browsing and send it to my site so I can analyze it for marketing research?
revert all visited links back to the unvisited-link color?
suppress the "hand" mouse pointer when the user moves the mouse over a link, so it can be a hidden link?
be sized at 640 x 480 no matter what the user's monitor size?
not have scroll bars no matter what the user's monitor size?
install my custom fonts on the user's system so my page displays the way I want it even if the user doesn't already have those fonts?
ignore user font-size-changing settings and controls and keep the fonts the same size no matter how they're set?
prompt the user to save a file to disk when the user clicks on it, rather than displaying it within the browser?
immediately run an EXE file from my site when the user clicks on it, rather than prompting the user to save the file?
print my order form on the user's printer immediately when he or she enters my site?
view my Web pages only as part of a frameset, and not individually?
view my Web pages only individually, not as part of a frameset?
suppress the "View Source" feature so nobody can steal my HTML code?
disable the "Save As" feature so nobody can steal my pages, graphics, and other elements?
suppress the "Print" button so nobody can steal my pages in hardcopy form?
suppress all right-clicking and copy-and-paste functions on my site?
pop up a warning box whenever a user tries to leave my site, to encourage him/her to stay?
save files the user downloads in the directory I choose, rather than a directory the user chooses?
suppress the warning dialog box that comes up (on some browser versions and configurations) when my site tries to run an ActiveX control, set a cookie, go between secure and insecure pages, etc.?
turn off JavaScript in the user's browser (to suppress the pop-up windows some free Web hosting services add)?
turn on JavaScript in the user's browser (to make sure all my neato special effects get displayed!)
suppress the display and printing of the URL of documents, so I can hide from the user how to retrieve a specific document directly and force him/her to go through my menu structure?
disable the "Bookmark" (or "Favorites") feature so the user can't bookmark my page?
automatically bookmark my page when the user visits it for the first time?
have my form automatically submit when the user presses ENTER?
have my form not automatically submit when the user presses ENTER?
suppress the dotted box that appears around clickable images when they're selected (in some versions of MSIE)?

...and the list goes on. They all display a lack of understanding of how the Web works. There is no way an author can force anything on the user. Various HTML constructs can suggest certain actions on the part of the browser, but they can't force them.

It is true that some newer (sometimes nonstandard) constructs and add-ons, especially scripting languages like JavaScript, can "force" various browser behavior, at least on the part of a browser that supports such activity. But on a browser that doesn't, and one in which such add-ons are disabled by user preferences, they can't force anything. (Some browsers, like Mozilla and Opera, are getting very good at developing sophisticated preference settings to let users disable some of the more annoying things a site can try to do, like pop-under ads, while still enabling most multimedia enhancements that can actually improve a site's quality.)

Even if it were possible to force such things on the user, the question is "Why do you want to do that?" A large portion of the user community is apt to get annoyed at such attempts to manipulate his or her browsing experience, and an annoyed user probably won't return to your Web site. Users are accustomed to using standard navigation tools like the browser's Back button, and won't like it if you somehow manage to disable them. Users may be using any number of different machine platforms and display resolutions, and may be unable or unwilling to force a particular pixel width just to suit your poorly-designed layouts that can't resize to the user's settings. Users may see a security risk in running embedded applets and scripts and will refuse to enable these settings, so if your site makes them mandatory for navigation he'll just go away.

The lack of ability to force browser behavior is certainly frustrating to developers who are used to creating standalone software products designed for one particular platform and that run completely from start to finish under the developer's control, but if you're developing for the Web, you'll have to lose that mindset and learn to accept the greater control the Web user has over the browsing experience.

Some Notes on Specific 'Force' Attempts

Here are some more specific comments on some of the particular things that people often wish to "force":

Forcing new browser windows to open, close, be sized to specific dimensions, and to lack normal controls like the Back button

If JavaScript is enabled, you can use it to do such things. But these are the sorts of things likely to annoy many users, as they change the normal user-interface of the browser, and if the user is low in memory, may even crash or hang the system. They can also get the user into "loops" where the same unwanted popup window keeps opening again every time the user closes it, increasing the annoyance level.

Removing sites from the "Back-Button" history

A very common request is to make it impossible for the user to return to a page via the Back button. Sometimes there's even a legitimate reason for this, like to prevent form elements from being submitted twice or out of order, or to protect the security of personal information entered on the page. Other times it's just an unreasonable desire on the part of a control-freak client who can't stand users choosing their own sequence of viewing their site, or even surfing on to other people's sites and coming back to the original site later. Either way, it's not possible. Even with scripting languages, I know of no way to remove sites from the user's history. If your need for this is for an intranet or kiosk where you control the browser, you might look for a custom-made browser that has such functions built in.

Forcing font face, size, and color settings regardless of browser settings

You can suggest font settings in various ways, including stylesheets and various (deprecated in HTML 4.0) presentational tags and attributes. On some browsers, some of these settings "force" your desired settings regardless of the user's configuration. This is a bad idea, because it can result in pages that are unreadable to users with special needs. For instance, those with poor eyesight might want larger fonts, and those with color-blindness might need to set color combinations that are readable to them, even if they look odd to others. The more the site author does to try to defeat such things, and the more the browser cooperates, the less readable the site will be to such users.

Forcing files to download, run, launch specific applications, etc.

You can't do that. The Web protocols were designed to identify, via MIME Content-Type headers, what sort of content a data stream has, but not specify exactly what to do with it. This was done for a good reason; the site author has no way of knowing exactly what sort of system the end user has, or that user's preferences as to how to deal with different kinds of data. And some ways of dealing with data, like automatically running an .exe file, pose security risks such as viruses and "trojan horses". And if the user has a Macintosh or a Unix system, running DOS or Windows .EXEs is infeasible, anyway; but if you let the user download the file, he might be able to put it on a disk and run it on a PC down the hall.

In general, users may want to make their own choices as to how to deal with various kinds of files, displaying them in their browser, displaying them via an external helper application, or saving them to their hard disk, rather than letting your site force one particular behavior that might not even work on this particular user's system. So you should make sure your server sends an honest and accurate Content-Type header for each item it sends.

If you're sending data files of some sort which the user ought to be saving instead of viewing in his/her browser, the best MIME type to use is application/octet-stream; this will usually cause a "save" dialog box to appear. It's not "forced" (a user can configure the browser to do something else with this sort of data), but it's the usual action, and this is the closest you can get to "forcing the browser to save the file." But you can't force the directory or filename it's saved under, though browsers will generally get the name out of the last part of the URL (though they can vary in maddening ways, sometimes winding up with weird filenames unlike the one you intended).

You can always encourage the user to make use of browser features to save a file to disk, such as right-clicking in Netscape or MSIE, which work no matter what MIME type is used or how the browser is configured to handle that type.

Suppressing warning dialog boxes

You might not like it that some browsers display "Security Risk Warnings" when your site tries to set a cookie, launch an applet or ActiveX control, go from secure (encrypted) to nonsecure pages and back again, or other activity that some browsers, under some configuration settings, warn about. Some authors dislike this so much that they ask if there's any way to force the disabling of such warnings. Well, if the Web author could do that, wouldn't that defeat the purpose of these warnings of possible security risks? Get real!

'Hiding' your page source code

This is probably the most common "How Do I Force..." request on the newsgroups these days. People have an exaggerated impression of the value of their HTML code and want to protect it from being "stolen." But there's no way to hide HTML source code from the user. The user's browser needs to receive all the HTML source code in order to display the page, so no matter what devious techniques the author uses to obscure the code, it still has to be parseable by the browser, and is thus not too hard for any halfway-intelligent user to turn into something readable.

One of the great things about the Web is that "newbies" can learn a lot about Web authoring by looking at the source code of pages. That's one of the ways I learned in the first place. By doing this, you'll see lots of examples (both good and bad) of Web authoring techniques, which may help you to eventually produce pages as nice as those of the professionals. The amateur/professional and beginner/expert gaps are much smaller in the Web than in other media, and it's perhaps out of a desire to widen this gap that some of the "professionals" want to find a way to hide their source code. But it still can't be done.

Similarly, there's no way to stop anyone from printing, bookmarking, or linking to your page. When you put something out on the Web, it's fair game for all of this. You still legally own copyright on everything you put on the Web (under present law you've got copyright to anything you create even if it doesn't have a copyright notice on it), and can sue somebody who distributes copies of it without your permission, but you can't stop normal Web use of your documents when they're on the Web, and that includes other sites making links to your page. If you want to make it harder on people, I guess you can keep moving your pages around so that anyone who links to one winds up with a 404 Not Found error the next day, but that would annoy your legitimate users at least as much as anyone you think is "ripping you off."

Some of the people who ask how to suppress the "View Source" feature are not doing this to prevent theft of their code, but because they want to maintain security of something in their code, such as an embedded password or other such thing which could be abused by "hackers" if they knew it. If this is the case, you need to completely re-think your site security plan. Nothing that is present in the code sent to the browser is secure from snooping by users trying to "hack" your site, not even things that are compiled into an applet (which can be decompiled by various utilities). You need to move any aspect of your site that requires security to the server side, not the client side. The server needs to be where passwords are compared, user status and history information is maintained, etc., if you want to be sure none of this is viewable or hackable by end users.

Suppressing right-clicks and copy-and-paste

This is closely related to the last one; lots of benighted individuals think they can stop people from "stealing" their site content if they put in annoying scripts that suppress right-clicks and text-copying. No, this doesn't work; it's trivial to disable JavaScript, and then the scripts do nothing at all. All they do is annoy normal users, who have lots of perfectly reasonable things they might want to do with right-clicking and text-copying, such as opening links in new tabs or copying short excerpts to use (under the fair use provision of copyright) in site reviews and commentary.

Submitting or not submitting a form with ENTER

This is entirely under the browser's control, not the site author's. Most browsers will submit on ENTER if there's exactly one text-input field, and not if there are more than one. There's no way to override this. (The presence of checkboxes and radio buttons don't seem to affect browser behavior in this area.)

That MSIE "dotted box"

A common question these days is "How do I disable the dotted box that appears around a clickable image in Microsoft Internet Explorer when it's selected?" Well, there's a "kludgy" way of disabling this, by putting in a JavaScript "onFocus" event that calls the "blur()" function to remove focus from the current object; but there are a lot of users who will be annoyed if you do this. The dotted box is an accessibility feature added by Microsoft to permit the browser to be used entirely from a keyboard without using the mouse. Some users prefer to surf this way, or have handicaps that make mouse-based navigation difficult or impossible. If you use JavaScript to defeat this feature, the users who want or need to navigate by keyboard will be compelled to disable JavaScript to use your site.

Hall of Shame

Make your site better by looking at other sites that show, by example, what not to do!

NOTE: The inclusion of a site in my "Hall of Shame" links should not be construed as any sort of personal attack on the site's creator, who may be a really great person, or even an attack on the linked Web site as a whole, which may be a source of really great information and/or entertainment. Rather, it is simply to highlight specific features (intentional or accidental) of the linked sites which cause problems that could have been avoided by better design. If you find one of your sites is linked here, don't get offended; improve your site so that I'll have to take down the link!

This site has made and attempted to defend a pathetic policy of disabling copy-and-paste via JavaScript... in 2013, would you believe?

[<== Previous] | [Up] | [Next ==>]